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We  Rely  on  Software  for  Safe  Aircraft  Operation 


Quantas 

Landing 

Written  by  htbv 
From:  soya  wan 


from  Singapore  to 


Even  with  the  autopilot  off,  flight  control  computers  still  '  '  command  control 
surfaces  to  protect  the  aircraft  from  unsafe  conditions  such  as  a  stall/'  the 
investigators  said. 

The  unit  continued  to  send  false  stall  and  speed  warnings  to  the  aircraft's 
primary  computer  and  about  2  minutes  after  the  initial  fault  "  '  generated 
very  high,  random  and  incorrect  values  for  the  aircraft's  angle  of  attack." 

mayday  call  when  it  suddenly  changed  altitude  during  a  flight 
Qantas  said. 


Embedded  software  systems 
introduce  a  new  class  of 
problems  not  addressed  by 
traditional  system  modeling  & 


i 


analysis 

, .  -  - 1- -- 


lunge 


wide 
imays 

causing  the 


Autopilot  Off 

A  "  "  preliminary  analysis"  of  the  Qantas  plunge  showed  the  error  occurred 
in  one  of  the  jet's  three  air  data  inertial  reference  units,  which  caused  the 
autopilot  to  disconnect,  the  ATSB  said  in  a  statement  on  its  Web  site. 

The  crew  flew  the  aircraft  manually  to  the  end  of  the  flight,  except  for  a 
period  of  a  few  seconds,  the  bureau  said. 


jet  to  nosedive. 


vas  cruising  at  37,000  feet  (11,277  meters) 
computer  fed  incorrect  information  to  the  flight  control  system,  the 
Australian  Transport  Safety  Bureau  said  yesterday.  The  aircraft  dropped 
650  feet  within  seconds,  slamming  passengers  and  crew  into  the  cabin 

r-o j ! j r] |  fipfTP  pji^r-  .-I  ^ntrrli 

"  This  appears  to  be  a  unique  event,"  the  burea^aid,  adding  that 


fitted  with  the  same  air-data  computer,  me  advisory  is  aimed  at 
minimizing  the  risk  in  the  unlikely  event  of  a  similar  occurrence." 


Even  with  the  autopilot  off,  flight  control  computers  still  "  "  command  control 
surfaces  to  protect  the  aircraft  from  unsafe  conditions  such  as  a  stall,"  the 
investigators  said. 

The  unit  continued  to  send  false  stall  and  speed  warnings  to  the  aircraft's 
primary  computer  and  about  2  minutes  after  the  initial  fault  "  "  generated 
very  high,  random  and  incorrect  values  for  the  aircraft's  angle  of  attack. 


ine  night  control  computer  then  commanded  a  nose-down  aircratt 

movement,  which  resulted  in  the  aircraft  pitching  down  to  a  maximum  of 
about  8.5  degrees,"  it  said. 

No  "  Similar  Event' 

Airbus  has  advised  that  it  is  not  aware  of  any  similar  event  over  the 
many  years  of  operation  of  the  Airbus,"  the  bureau  added,  saying  it  will 
continue  investigating. 
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Embedded  SW  System  Engine 


Concurrency 

Communication 

ITunes  crashes  on  dual-cores 


Embedded  software  system 
as  major  source  of  hazards 


Why  do  system  level  failures  still  occur  despite  fault 
tolerance  techniques  being  deployed  in  systems? 
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Multi-Fidelity  End-to-end  Latency  in  Control 
Systems 


Operational 
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System  Engineer 


System 
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Control  Engineer 


Control 

System 


Common  latency  data  from  system  engineering 

•  Processing  latency 

•  Sampling  latency 

•  Physical  signal  latency 
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Unstable  Systems 
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Impact  of  Scheduler  Choice  on  Controller  Stability 
A.  Cervin,  Lund  U.,  CCACSD  2006 
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Software-Based  Latency  Contributors 


Execution  time  variation:  algorithm,  use  of  cache 
Processor  speed 
Resource  contention 
Preemption 

Legacy  &  shared  variable  communicatior 
Rate  group  optimization 
Protocol  specific  communication  delay 
Partitioned  architecture 
Migration  of  functionality 
Fault  tolerance  strategy 


Flow  Use  Scenario  through  Subsystem  Architecture 
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The  Symptom:  Missed  Stepper  Motor  Steps 

Stepper  motor  (SM)  controls  a  valve 

•  Commanded  to  achieve  a  specified  valve  position 

-  Fixed  position  range  mapped  into  units  of  SM  steps 

•  New  target  positions  can  arrive  at  any  time 

-  SM  immediately  responds  to  the  new  desired  position 

Safety  hazard  due  to  software  design 

•  Execution  time  variation  results  in  missed  steps 

•  Leads  to  misaligned  stepper  motor  position  and  control  system  states 

•  Sensor  feedback  not  granular  enough  to  detect  individual  step  misses 


Software  modeled  and  verified  in  SCADE 

Full  reliance  on  SCADE  of  SM  &  all  functionality 
Problems  with  missing  steps  not  detected 


Software  tests  did  not  discover  the  issue 

Time  sensitive  systems  are  hard  to  test  for. 


Two  Customer  Proposed  Solutions 

Sending  of  data  at  12ms  offset  from  dispatch 
Buffering  of  command  by  SM  interface 
No  analytical  confidence  that  the  problem  will  be  addressed 


Other  Challenge  Problems 

Aircraft  wheel  braking  system 
Engine  control  power  up 
Situational  Awareness  &  health  monitoring 


Time-sensitive  Auto-brake  Mode  Confusion 


Auto-brake  mode  selection  by  push  button 

•  Three  buttons  for  three  modes 

•  Each  button  acts  as  toggle  switch 

Event  sampling  in  asynchronous  system  setting 

•  Dual  channel  COM/MON  architecture 

•  Each  COM,  MON  unit  samples  separately 

-  Button  push  close  to  sampling  rate  results  in  asymmetric  value  error 

-  COM/MON  mode  discrepancy  votes  channel  out 

-  Repeated  button  push  does  not  correct  problem 

-  Operational  work  around  (1  second  push)  is  not  fool  proof 
Avoidable  complexity  design  issue 

•  Concept  mismatches:  desired  state  by  event  and  sampled  event  processing 

•  Desirable  solution:  State  communication  by  multi-position  switch 
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SAE  Architecture  Analysis  &  Design  Language 
(AADL)  for  Software-reliant  Systems 


The  Mechanical  System 


Command  & 
Control 
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Embedded  Operational 
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Software 


SW  Design  &  Runtime 
Architecture 
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Deployed  on 
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:  p-cCu*»Torrr 
;  HCSt+ror+W 


Physical  interface 
Platform  component 


Computer  System 
Hardware  &  OS 


The  Computer  System 


AADL  focuses  on  interaction  between  the  three  elements  of  a 
software-reliant  mission  and  safety-critical  systems. 
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Architecture-Centric  Quality  Attribute  Analysis 


Single  Annotated  Architecture  Model  Addresses 
Impact  Across  Operational  Quality  Attributes 


Safety 
&  Reliabilit 

•MTBF 
•FMEA 

•Hazard 
analysis 


Architecture  Mode 


Data 

Quality 

•Data  precision/ 
accuracy 

•Temporal 

correctness 

•Confidence 


Auto-generated 
analytical  models 
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Real-time 

Performance 

•Execution  time/ 
Deadline 

•Deadlock/starvation 
•Latency 


Security 

•Intrusion 

•Integrity 

•Confidentiality 


Resource 

Consumption 

•Bandwidth 

•CPU  time 

•Power 
consumption 
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Aircraft:  (Tier  0) 


Early  Discovery  and  Incremental  V&V  through 
System  Architecture  Virtual  Integration  (SAVI) 


Aircraft  system:  (Tier  1) 

Engine,  Landing  Gear,  Cockpit,  ... 
Weight,  Electrical,  Fuel,  Hydraulics,... 


HydraulicPower  <j 


LRU/IMA  System:  (Tier  2) 

Hardware  platform,  software  partitions 
Power,  MIPS,  RAM  capacity  &  budgets 
End-to-end  flow  latency 


System  &  SW  Engineering: 

Mechatronics:  Actuator  &  Wings 
Safety  Analysis  (FHA,  FMEA) 
Reliability  Analysis  (MTTF) 
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<<BusAccess>> 
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c<pusAccess>> 


— E>  ElectricalSupply 
f~ HydraulicPower 

Signals 


OEM  &  Subcontractor: 

Subsystem  proposal  validation 
Functional  integration  consistency 
Data  bus  protocol  mappings 


El 


Subcontracted  software  subsystem:  (Tier  3) 
Tasks,  periods,  execution  time 
Software  allocation,  schedulability 
Generated  executables 


Ap~»jj)  analogl  >  11= 


navSensorDataFromNSP 
/  navDataT oGPAPC 
— : - W - 


Repeated  Virtual  Integration  Analyses: 
Power/weight 
MIPS/RAM,  Scheduling 
End-to-end  latency 
Network  bandwidth 


Proof  of  Concept  Demonstration  and  Transition  by  Aerospace  industry  initiative 

•  Architecture-centric  model-based  software  and  system  engineering 

•  Architecture-centric  model-based  acquisition  and  development  process 

•  Multi  notation,  multi  team  model  repository  &  standardized  model  interchange 

■  Multi-tier  system  &  software  architecture  (in  AADL) 

■  Incremental  end-to-end  validation  of  system  properties 
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Rapid  Architecture  Trade  Study 

Help  designers  to  choose  the  best  Architecture 
Best  reliability,  avoid  potential  failure/error 
Meet  timing  and  performance  requirements 

Analyze  operational  quality  attributes  from  three  perspectives 
Safety/Reliability 
Latency 

Resources  and  Budgets 
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Latency  Analysis 
results 


Architecture 
Alternative  1 


Contributor 

Min  Value 

Min  Method 

Max  Value 

Max  Method 

Device  obstacle_camera 

0.0ms 

first  sampling 

0.0ms 

first  sampling 

Device  obstacle_camera 

20.0ms 

processing  time 

50.0ms 

processing  time 

Sampled  Connection  obstac 

0.0ms 

no  latency 

0.0ms 

no  latency 

Thread  t h r_a c q 

0  ms 

sampling 

50.0ms 

sampling 

Thread  t h r_a c q 

10.0ms 

processing  time 

40.0ms 

processing  time 

Sampled  Connection  image 

0.0ms 

no  latency 

0.0ms 

no  latency 

Thread  thr 

0  ms 

sampling 

100.0ms 

sampling 

Thread  thr 

20.0ms 

processing  time 

50.0ms 

processing  time 

Sampled  Connection  obstac 

0.0ms 

no  latency 

0.0ms 

no  latency 

Bus  bust 

200.25ms 

transmission  time 

500.625ms 

transmission  time 

Thread  thr 

0  ms 

sampling 

10.0ms 

sampling 

Thread  thr 

0.0ms  | 

no  latency  1 

lo.Oms 

no  latency 

Sampled  Connection  obstac 

0.0ms 

no  latency 

0.0ms 

no  latency 

Thread  thr 

0  ms 

sampling 

4.0ms 

sampling 

Thread  thr 

0.0ms 

no  latency 

0.0ms 

no  latency 

Sampled  Connection  emerg 

0.0ms 

no  latency 

0.0ms 

no  latency 

Thread  thr 

0  ms 

sampling 

2.0ms 

sampling 

Thread  thr 

0.0ms 

no  latency 

0.0ms 

no  latency 

Sampled  Connection  warnin 

0.0ms 

no  latency 

0.0ms 

no  latency 

Device  warning_alert 

0  ms 

sampling 

500.0ms 

sampling 

Device  warning  alert 

20.0ms 

processing  time 

50.0ms 

processing  time 

Latency  Total 

270.25ms 

1356.625ms 

End  to  End  Latency 

700.0ms 

900.6ms 

Software  Engineering  Institute 


Contributor 

Min  Value 

Min  Method 

Max  Value 

Max  Method 

Device  obstacle_camera 

0.0ms 

first  sampling 

0.0ms 

first  sampling 

Device  obstacle_camera 

20.0ms 

processing  time 

50.0ms 

processing  time 

Sampled  Connection  obstacle_car 

0.0ms 

no  latency 

0.0ms 

no  latency 

Thread  thr_acq 

0  ms 

sampling 

50.0ms 

sampling 

Thread  thr_acq 

10.0ms 

processing  time 

40.0ms 

processing  time 

Sampled  Connection  image_acqui 

0.0ms 

no  latency 

0.0ms 

no  latency 

Thread  thr 

0  ms 

sampling 

100.0ms 

sampling 

Thread  thr 

20.0ms 

processing  time 

50.0ms 

processing  time 

Sampled  Connection  obstacle_det 

0.0ms 

no  latency 

0.0ms 

no  latency 

Bus  can 

10.000125ms 

transmission  time 

30.00125ms 

transmission  time 

Thread  thr 

0  ms 

sampling 

10.0ms 

sampling 

Thread  thr 

0.0ms 

no  latency 

0.0ms 

no  latency 

Sampled  Connection  obstacle_dis' 

0.0ms 

no  latency 

0.0ms 

no  latency 

Thread  thr 

0  ms 

sampling 

4.0ms 

sampling 

Thread  thr 

0.0ms 

no  latency 

0.0ms 

no  latency 

Sampled  Connection  emerge  ncy_< 

0.0ms 

no  latency 

0.0ms 

no  latency 

Thread  thr 

0  ms 

sampling 

2.0ms 

sampling 

Thread  thr 

0.0ms 

no  latency 

0.0ms 

no  latency 

Sampled  Connection  waming_acth 

0.0ms 

no  latency 

0.0ms 

no  latency 

Device  waming_alert 

0  ms 

sampling 

500.0ms 

sampling 

Device  warning  alert 

20.0ms 

processing  time 

50.0ms 

processing  time 

Latency  Total 

80.000125ms 

886.00125ms 

End  to  End  Latency 

700.0ms 

900.0ms 
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Analysis  Summary 


Architecture  1 

Architecture  2 

Latency 

© 

X 

Resources  Budgets 

© 

Safety 

© 

Cost 

© 

X 

What  is  the  “best”  architecture? 
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Certification  &  Recertification  Challenges 

Certification:  assure  the  quality  of  the  delivered  system 

•  Sufficient  evidence  that  a  system  implementation  meets  system  requirements 

•  Quality  of  requirements  and  quality  of  evidence  determines  quality  of  system 
Certification  related  rework  cost 

•  Currently  50%  of  total  system  cost  and  growing 
Recertification  Challenge 

•  Desired  cost  of  recertification  in  proportion  to  change 

Improve  quality  of  requirements  and  evidence 

Perform  verification  compositionally 
throughout  the  life  cycle 
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Requirement  Quality  Challenge 


Requirements 

error 

% 

Incomplete 

21% 

Missing 

33% 

Incorrect 

24% 

Ambiguous 

6% 

Inconsistent 

5% 

r  ^ 

There  is  more  to  requirements  quality  than  “shall”s  and  stakeholder  traceability 
IEEE  830-1998  Recommended  Practice  for  SW  Requirements  Specification 

J 


UserReqts  Technical  Reqts  Design  Test  Cases 


Browsable  links/Coverage  metrics 


IEEE  Std  830-1998  characteristics  of  a  good  requirements  specification: 

•  Correct 

•  Unambiguous 

•  Complete 

•  Consistent 

•  Ranked  for  importance  and/or  stability 

•  Verifiable 

•  Modifiable 

•  Traceable 


System  to  SW  requirements  gap  [Boehm  2006] 

How  do  we  verify  low  level  SW  requirements 
against  system  requirements? 


When  StartUpComplete  is  TRUE  in  both  FADECs  and 
SlowStartupComplete  is  FALSE, 

the  FADECStartupSW  shall  set  SlowStartupInComplete 
to  TRUE 


=-  Software  Engineering  Institute  Carnegie  Mellon 


Integrated  Development  and  Assurance 
Feiler,  Jan  26,  2015 

©  2015  Carnegie  Mellon  University 


19 


Mixture  of  Requirements  &  Architecture  Design  Constraints 


Requirements  for  a 
Patient  Therapy  System 

The  patient  shall  never  be  infused 
with  a  single  air  bubble  more  than 
Sml  volume. 

When  a  single  air  bubble  more 
than  Sml  volume  is  detected, 
the  system  shall  stop  infusion 
within  0.2  seconds. 

When  piston  stop  is  received^the 
system  shall  stop  piston  movement 
within  0.0 1  seconds. 

The  system  shall  always 
stop  the  piston  at  the 
bottom  or  top  of  the 
chamber 


Requirements  and  Design  Information 


The  patient  shall  never  be  infused 
with  a  single  air  bubble  more  than 


3.  When  piston  stop  is  received, the 

system  shall  stop  piston  movement 
within  0.01  seconds. 


When  a  singleair  bubble  more 
than  5 ml  volume  is  detected, 
the  system  shall  stop  infusion 
within  0.2  seconds. 


The  system  shall  always 
stop  th  e  piston  at  th  e 
bottom  or  top  of  th  e 
chamber. 


Adapted  from  M.  Whalen  presentation 


Typical  requirement  documents  span  multiple  levels  of 

a  system  architecture 

We  have  made  architecture  design  decisions. 

We  have  effectively  specified  a  partial  architecture 
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System  Specification  and  Requirements 
Coverage 


{  Developmental'* 
Requirements 


Quality  attribute  utility  tree 


Modifiability  i 


Assurability  i 


Environmental  Assumptions 


Requirements 

Guarantees 

Assumptions 


Precondition 

\ 

- > 

State 

1  1  w  1  1 VJ  III  1  1 

Postcondition 

\  r 

Resources 

Invariant 

Interaction  contract: 
match  input  assumption 
with  guarantee 


—  Performance 


QA  — 
Utility 


—  Availability 


■-G 

l 

■f 


Latency  — 

Transaction 
■Througl^pot 
New  products 

Change 
COTS 


COTS  SW 
failures 


r - '•  Reduce  storage  latency  on 

customarDEto  <  200  ms. 

I .  De  liver  video  in  real  time. 

itUli  Add  COREA  middleware 
20  person-months. 

Ch  a  nge  Web  u  ser  into  rface 
"  ■’  person -weeks. 

Power  outage  at  site  1  requires  traffic 
redirected  to  she2  in  <  3  seconds. 

Network  fa  ilure  detected  and  recovered 
(H,H}  in  <  1 .5  minutes . 

(HtM) 


Data 
confidentiality 
Data 
integrity 


fuels  I  L 

in  <2i 

link) 

(H,H 

-c 

(H,H 
(H,W 

ity  j 


JH.LJ 


Customer  DB  authorization  works 
99.#99%  of  trie  time. 


(  Mission  N 
Requirements  " 


Function  i 


Behavior  i 


I 


- ,  | 

.Performance!  I 


(  Dependability  N 


.  Requirements 

■  r - \ 

Reliability  i 
_  _  _  _  _  -✓ 

I 

______  -✓ 

r - \ 

Security  i 
_  _  _  _  _ 


Safety 


_ s  v _ J 


Implementation  constraints 


Exceptional  condition 
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Architecture-led  Requirement  &  Hazard  Specification 


Requirements 
Guarantees 
Assumptions 

Precondition 

Postcondition 

Invariant 


System  Specification  Coverage 


Mission-  X 
1  critical 
.  Requiremen  | 


Function 

Behavior 

Performance 


l 


_  .'ll .  / 


Implementation  constraints 
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Safety  Practice  in  Development  Process  Context 


AIRCRAFT 

REQUIREMENTS 

IDENTIFICATION 

41.4- 


SYSTEM 

REQUIREMENTS 

1 

1 

1 

1 

1 

ITEM 

REQUIREMENTS 

ITEM  DESIGN 

1 

1 

1 

1 

l 

ITEM 

VERIFICATION 

1 

1 

1 

1 

1 

-s- 

1 

1 

SYSTEM 

VERIFICATION 

1 

1 

1 

1 

1 

IDENTIFICATION 

IDENTIFICATION 

41.58,4  3 

4.1.78,45 

4.6  28,4.6.3 

l 

l 

5.5 

5.5 

1 

1^ 

AIRCRAFT 

VERIFICATION 


Labor-intensive 
Early  in  system  engineering 
Rarely  repeated  due  to  cost 


Focus  on  System  Engineering  Largely 
Ignores  Software  as  Hazard  Source 


wrtirMcjgS 
irespecCprrS- 

ManulBcluriitg 
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AADL  Error  Model  Scope  and  Purpose 


System  safety  process  uses  many  individual  methods  and  analyses,  e.g. 

•  hazard  analysis 

•  failure  modes  and  effects  analysis/ 

•  fault  trees 

•  Markov  processes 


Qyst^  Capture  hazards 


p 

(Component)  Capture  FMEA  model 


Capture  risk  mitigation  architecture 


Goal:  a  general  facility  for  modeling  fault/error/failure  behaviors  that  can  be 
used  for  several  modeling  and  analysis  activities. 

Annotated  architecture  model  permits  checking  for  consistency 
and  completeness  between  these  various  declarations. 


Related  analyses  are  also  useful  for  other  purposes,  e.g. 


•  maintainability 

•  availability 

•  Integrity 

•  Security 


SAE  ARP  4761  Guidelines  and  Methods  for  Conducting  the  Safety 
Assessment  Process  on  Civil  Airborne  Systems  and  Equipment 
Demonstrated  in  SAVI  Wheel  Braking  System  Example 


Error  Model  Annex  can  be  adapted  to  other  ADLs 
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Error  Propagation  Contracts 


Incoming 


Binding 


Incoming/Assumed 

•  Error  Propagation  Propagated 
errors 


BadValue 
NoData 


Outgoing 


Late  Data 


Legend 


>• 


Port 


HW  Binding 


Propagation 
of  Error  Types 
Direction 


Propagated 
Error  Type 


Not 

propagated 


Error  Flow  through  component 
Path  PI. NoData->P2. NoData 
Source  P2.BadData 

Path  processor.NoResource  ->  P2. NoData 


“Not"  on  propagated  indicates  that  this 
error  type  is  intended  to  be  contained. 

This  allows  us  to  determine  whether 
propagation  specification  is  complete. 


•  Error  Containment:  Errors  not 
propagated 


Outgoing/Contract 

•  Error  Propagation 

•  Error  Containment 


Bound  resources 

•  Error  Propagation 

•  Error  Containment 

•  Propagation  to  resource 


=-  Software  Engineering  Institute  Carnegie  Mellon 


Integrated  Development  and  Assurance 
Feiler,  Jan  26,  2015 

©  2015  Carnegie  Mellon  University 


26 


Original  Preliminary  System  Safety  Analysis 
(PSSA) 


EGI 


A 


Anticipated: 
No  EGI  data 


Oper’l  [  NoData  1  [  NoData  | 


Flight  Mgnt  Syster 


Auto  Pilot 


Anticipated: 

NoService 


|  Failed  | 


Airspeed 
Data 


Operational 

Failed 

f 

FMS  \ 
Processor 


NoService] 


i 

.  j 


Anticipated:  No 
Stall  Propagation 


FMS  Power 


System  engineering  activity  with 
focus  on  failing  components. 
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Discovery  of  Unexpected  PSSA  Hazard  through 
Repeated  Virtual  Integration 


system  Ell 
features 

trueairspeed :  out  data  port  DataDictionary :: Velocity; 

flows 

f 1 :  flow  sour 


Latency  = 

}; 

annex  EMV2  { 
error  prc 
use  type: 
use  beha\ 
true, 
flows 
efl:err< 
ef2:errc 
properties 
EMV2 : : hazard 
[  crossreft 
failure  : 
phase  => 
descriptd 
severity 
critical: 
comment  : 


system  implem 
subcomponen 

PilotGrip 
Positions 
EGI :  syst 
FMS:  proce? 


EGI 


'N 

[  Anticipated: 

r  > 

Anticipated: 

Ino  EGI  data 

Flight  Mgnt  Syster 

^  NoService 

Auto  Pilot 


jcorrupted^ 


EGI  HW 


peed  reading  due  to  synchronizatioi 


Oper’l  /  c 
I  Failed] 


Unexpected  propagation  of 
corrupted  Airspeed  data  results 
in  Stall  due  to  miss-correction 


FMS 


Actuator 

Cmd 


Actuatorl:  device  Actuator 
Actuator2:  device  Actuator 
FMSProcessor :  processor  PowerP< 
connections 


Vibration  causes  boards  to 
touch  which  causes  EGI 
data  corruption 


pilotCmd:  port  PilotGrip . Desir^ 
sensedPosition :  port  PositionSensor . PositionReading  ->  FMS . Position; 
ActuatorlCmd :  port  FMS.ActCmd  ->  Actuatorl .ActCmd; 

Actuator2Cmd :  port  FMS.ActCmd  ->  Actuator2 .ActCmd; 

vtx:  port  EGI.TrueAirSpeed  ->  FMS.TrueAirSpeed ; _ 


©Outgoing  propagation  {Failure,  CorruptedData}  is  not  handled.  Expected  incoming  {Failure} 


NoService] 

"sjair;;] 


Anticipated:  No 
Stall  Propagation 


FMS  Power 


EGI  maintainer  adds  corrupted  data  hazard  to  model. 
Error  Model  analysis  of  integrated  model  detects 
unhandled  propagation. 


-s  HL  LUd  LUI  ‘XCIIIU - z'  RLlUdlUll.  Tb 

{ 

Latency  =>  15  ms  . .  20  ms; 

}; 
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Recent  Automated  FMEA  Experience 

Failure  Modes  and  Effects  Analyses  are  rigorous  and  comprehensive 
reliability  and  safety  design  evaluations 

•  Required  by  industry  standards  and  Government  policies 

•  When  performed  manually  are  usually  done  once  due  to  cost  and  schedule 

•  If  automated  allows  for 


-  multiple  iterations  from  conceptual  to  detailed  design 

-  Tradeoff  studies  and  evaluation  of  alternatives 

-  Early  identification  of  potential  problems 


- 

ID  Item  Initial  State  Initial  Failure  Mode  1st  Level  Effect  Transition  2nd  Level  Effect  Transition  3rd  Level  Effect  Severity  M 

1 

Sat:Bus 

Working 

Failure 

Failed 

Failed 

Recovery 

Working 

Workir 

1 

Sat Payload 

Working 

Working 

Bus  failure  causes  payload  transition 

Standby 

Standby 

Bus  Recovery  Causes  Payload  Transition 

Workir 

2 

Sat Bus 

Working 

Working 

Working 

5 

2 

Sat_Payload 

Working 

Failure 

Failed 

Recovery 

Working 

5 

Largest  analysis  of  satellite  to  date  consists  of  26,000  failure  modes 

•  Includes  detailed  model  of  satellite  bus 

•  20  states  perform  failure  mode 

•  Longest  failure  mode  sequences  have  25  transitions  (i.e.,  25  effects) 

Myron  Hecht,  Aerospace  Corp. 

Safety  Analysis  for  JPL,  member  of  DO-178C  committee 
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Quality  &  Certification  Improvement  Strategy 


2010  SEI  Study  forAMRDEC 
Aviation  Engineering  Directorate 


Architecture-led 

Architecture-centric 

Static  Analysis  & 

Incremental  Assurance 

Requirement 

Virtual  System 

Compositional 

Plans  &  Cases 

Specification 

Integration 

Verification 

throughout  Life  Cycle 

r 

Mission 

\ 

Requirements 

Function 

Behavior 

L 

Performance 

) 

r 
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Requirements 

Reliability 

Safety 

L 

Security 
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Model 

Repository 


Component 

Models 


System 

Implementation 


Operational 
&  failure 
modes 

Resource, 
Timing  & 
Performance 
Analysis 

Reliability, 

Safety, 

Security 

Analysis 


Four  pillars  for  Improving  Quality  of  Critical  Software-reliant  Systems 
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Building  the  Assurance  Case  throughout  the  Life  Cycle 


Case 


=■  Software  Engineering  Institute 


Integrated  Development  and  Assurance 

Carnegie  Mellon  Feiler- Jan  26- 201 5 

(ch  9H1  R  Pamonia  Mallrtn  I  I 


)  2015  Carnegie  Mellon  University 


Virtual  System  Integration  &  Compositional  Verification 


Continuous  Confidence  Measure  throughout  Life 
Cycle  that  a  System  Meets  its  Requirements 


Architecture-centric  Virtual  Integration 


Architecture  Led 
Requirements  Specification 

V  1 

ts 

J 

Deployment 

Build 

Flight  Test 

v  J 

/  Early  Discovery  through  Architecture  Analysis 
System &SVv\  leads  to  Assurance  Related  Reworir^ — ' — - 

\ 

Virtual  Architecture 
Integration  &  Analysis 

“component 


Lab  Testing 


Incremental  Evolution  and 
Execution  of  Assurance  Plans 


Incremental  Architecture  & 
Requirement  Evolution 


Design  &  Req 
Refinement 


Requirement 

Coverage 


Verification 


Software 

Design 


Design  Validation  by 
Virtual  Integration 


-Integration 
A  Test 


Code 
evelopment 


Af  /  N 

a 

w/Jy 

7  The  system  nufe 

Auto-generation  from 
verified  models 

AADL&SCADE/Simulink 
Ada  SPARK/Ravenscar 
MISRAC 


Design  &  Req 
Refinement 


Incremental  Contract-based 
Compositional  Verification 


C3 

■  iiiiJd  D  tra 
IfW"  hIii  jfimV;) 


Lfi  \ 


Auto-generated  Assurance  Cases 


Build  the  System 
Build  the  Assurance  Case 
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Contract-based  Compositional  Verification 

Secure  Mathematically-Assured  Composition  of  Control  Models 


Key  Problem 

Many  vulnerabilities  occur  at  component  interfaces. 
How  can  we  use  formal  methods  to  detect  these 
vulnerabilities  and  build  provably  secure  systems? 


TA4  -  Research  Integration  and 
Formal  Methods  Workbench 
Rockwell  Collins  and 
University  of  Minnesota 


ARCHITECTURE-CENTRIC  PROOF 


Formal  System 
Requirements 


J7 


System  Architectur 

System  Design 
Compositional  Verifica 
and  Synthesis 


16  months  into  the  project 


Draper  Labs  could 
system  in 


not  hack  into  the 
6  weeks 


Had  access  to  source  code 


Technical  Approach 

Develop  a  complete,  formal  architecture  model  for  UAVs  that 
provides  robustness  against  cyber  attack 

Develop  compositional  verification  tools  driven  from  the 
architecture  model  for  combining  formal  evidence  from  multiple 
sources,  components,  and  subsystems 

Develop  synthesis  tools  to  generate  flight  software  for  UAVs 
directly  from  the  architecture  model,  verified  components,  and 
verified  operation  system 


Accomplishments 


Created  AADL  model  of  vehicle  hardware  &  software 
architecture 

Identified  system-level  requirements  to  be  verified 
based  on  input  from  Red  Team  evaluations 

Developed  Resolute  analysis  tool  for  capturing  and 
evaluating  assurance  case  arguments  linked  to 
AADL  model 

Developed  example  assurance  cases  for  two 
security  requirements 

Developed  synthesis  tool  for  auto-generation  of 
configuration  data  and  glue  code  for  OS  and  platform 
hardware 


Software  Engineering 


Integrated  Approach  to  Requirement  V&V 
through  Assurance  Automation 


]  CastfogtlonCofitrol.a»dl  |  €  requuements.rdaLdiagram 

SSMS 


'/  SMS-IA-REQ1:  Input ... 
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Requirement  coverage 
Assumption  evidence 


□_  Problems  |  Uj  Properties  [VJ  AAUL  Property  Valuesj  j^j  iraceability  W  Assurance  Case 


t>  Requirements  Group  SafetyHazards 
d  Q  Requirements  Group  ACT 

t>  t_.  Requirement  ACT-SB-REQ2:  queue  size  zero  and  abor 
[>  /  Requirement  ACT-SS_REQ9:  Homing  command  resul 

t>  /  Req  u  i  rem  ent  ACT-  0  G  -  REQ5 :  M  axStepC  o  u  nt  of  15  i  s  i 
/  Req  u  i  rem  ent  ACT-  SB  -  REQ6 :  Step  C  o  u  nt  =  =  zero  wh  er 
/  Requirement  ACT-IA-REQ7:  Step  count  within  range 
[>  /  Requirement  ACT-SS-REQ1:  command  arrival  driven 

|>  Requirement  ACT- SB- REQ4:  StepCount  ==  #  of  step  : 

*  n  ■  i  irr  ii  nrnn  n  i  n  n  - 


Evidence  records  in  terms  of  claims 
that  requirements  have  been  met 
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Linkage  to  automated  test  harnesses 
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Incremental  Development  and  Assurance 
Practice 


Iterative  architecture 
design,  safety  analysis,  and 
requirement  decomposition 


Stakeholder  and 
Quality  Attribute  (QA) 
driven  architecture¬ 
centric  requirement 
specification 


Transformation  and 
code  generation  based 
on  verified  architecture 
specifications 


SYSTEM 


Architecture-centric  virtual 
integration  and  compositional 
verification  of  requirements 


Testing  against 
verified  specifications 
and  models 


Assurance  plan 
and  execution 
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Benefits  of  Incremental  Life  Cycle  Assurance 
through  Virtual  System  Integration 


Reduce  risks 

•  Analyze  system  early  and  throughout  life  cycle 

•  Understand  system  wide  impact 

•  Validate  assumptions  across  system 
Increase  confidence 

•  Validate  models  to  complement  integration  testing 

•  Validate  model  assumptions  in  operational  system 

•  Evolve  system  models  in  increasing  fidelity 
Reduce  cost 

•  Fewer  system  integration  problems 

•  Fewer  validation  steps  through  use  of  validated  generators 
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